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STATUS OF THIS MEMO 


This paper describes the requirements for a graphical format on which 
to base a graphical on-line communication protocol. The proposal is 

an Interactive Graphical Communication Format using the GKSM session 

metafile. Distribution of this memo is unlimited. 


ABSTRACT 


This paper describes the requirements for a graphical format on which 
to base a graphical on-line communication protocol. It is argued that 
on-line graphical communication is similar to graphical session 
capture, and thus we propose an Interactive Graphical Communication 
Format using the GKSM session metafile. 


We discuss the items that we believe complement the GKSM metafile as 
a format for on-line interactive exchanges. One key application area 
of such a format is multi-media on-line conferencing; therefore, we 
present a conferencing software architecture for processing the 
proposed format. We make this format specification available to those 
planning multi-media conferencing systems as a contribution toward 
the development of a graphical communication protocol that will 
permit the interoperation of these systems. 


We hope this contribution will encourage the discussion of multimedia 
data exchange and the proposal of solutions. At SRI, we stay open to 
the exploration of alternatives and we will continue our research and 
development work in this problem area. 
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ale INTRODUCTION 
A. Use of a Graphical Communication Protocol 


In the field of computer communications, a protocol is a procedure 
executed by two cooperating processes in order to attain a 
meaningful exchange of information. A graphical communication 
protocol is needed to exchange interactive vector graphics 
information, possibly in conjunction with other information media 
like voice, text, and video. Within this multi-media communication 
environment, computer vector graphics plays a key role because it 
takes full advantage of the processing capabilities of 
communicating computers and human users, and thus it is far more 
compact than digital images which are not generated from data 
structures containing positional information. Vector graphical 
communication trades intensive use of storage and processing, at 
the communicating ends, in return for a low volume of exchanged 
data, because workstations with graphical hardware exchange 
graphics commands in conjunction with large data structures at the 
transmitter and receivers. In this manner, the transmission of a 
single command can produce extensive changes in the data displayed 
at the sending and receiving ends. 


It is helpful to situate the aforesaid protocol at one of the 
functional levels of the ISO Open Systems Interconnection 
Reference Model [1]. Within such a model, a graphical protocol 
functionality belongs primarily in the application level, though 
some of it fits in the presentation level. We can distinguish the 
following components of a communication protocol: 


a data format 

rules to interpret transmitted data 
state information tables 

message exchange rules 


aap 


) 
) 
) 
) 


A format for a graphical protocol should provide the layout of the 
transmitted data, and indicate how the formated data are 
associated with interpretation rules. The choice of format 
influences the state tables to be maintained for the correct 
processing of the transmitted data stream. The graphical format 
has a minor influence on the exchange rules, which should provide 
for the efficient use of transmission capacity to transport the 
data under such a format. Besides the graphical format, there are 
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other aspects of a graphical protocol that determine state tables 
and exchange rules. This paper concentrates in the data format, 
and it does not discuss the message exchange. Nevertheless, we 
discuss a simple software architecture for generating and 
interpreting data streams written in our proposed format. Further, 
we give an example of an application of a proposed format (in 
Appendix B), and it illustrates the type of message exchanges that 
are needed for establishing a communication session and exchanging 
graphical information. 


Those in the computer communication field are well aware of the 
importance of widely accepted protocols in order to achieve 
meaningful communication. Those who need to implement interactive 
graphical communications today are confronted with the lack of an 
standard for computer graphics communication among application 
programs. Nevertheless, we can use some of the work already done 
by the computer graphics standard bodies. As a matter of fact, ISO 
and ANSI have already appended, to the Graphical Kernel System 
(GKS) standard, the GKSM session metafile specification that has 
many of the features needed for an on-line graphical protocol. 


It is pertinent to mention an example of graphical communication 
that illustrates the real-time nature of the interaction and also 
illustrates the use of graphics in conjunction with other 
information media. With audio-graphics conferencing, a group of 
individuals at two or more locations can carry on an electronic 
meeting. They can converse over voice channels and concurrently 
share a graphics space on which they can display, point at, and 
manipulate vector graphics pictures [2, 3, 4, 5, 6, 7]. 


The conference voice channels can be provided by a variety of 
transmission technologies. The shared graphics space can be 
implemented on workstations that display the pictures and permit 
graphical interaction and communication with other locations. The 
communication of operations upon pictures involves modifications 
to the underlying data structures, but we are concerned with 
graphical database updating only to the extent that such updating 
supports the communication. 


In order to play out a recorded graphical session, we will need 
indications of the rate at which the graphical elements must be 
shown and the graphical operations recreated. We do not include 
the means for indicating the timing of a session in a format 
because our main purpose is to use it in mixed-media communication 
environments. In these environments, the play-out timing must be 
compatible across information media in order to coordinate them. 
Therefore, we leave the timing mechanisms to conference-control 
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modules. We also leave to conference control processes the manner 
in which a conferee station emulates a graphical capability that 
it lacks. One example is the representation of color in monochrome 
displays. 


B. Relationship to Other Work 


There are a number of actual, and proposed, standards for graphics 
information exchange. In the following, we explain the reasons 
why, at present, none of them can be used as the basis of an 
on-line protocol. As some of these standards evolve, however, some 
may become suitable. Moreover, the experience gained with early 
on-line graphics communication systems will provide insight into 
the proper standard extensions to support more advanced systems. 
Such insight could also be used to modify the format proposed in 
this paper, which we consider an initial approach to the problem. 
In the future, the format proposed in this paper could be replaced 
by one of the aforesaid extended standards. 


The North American Presentation Level Protocol Syntax, NAPLPS, 
specifies a data syntax and application semantics for one-way 
teletext information dissemination and two-way videotex database 
access and transaction services. The two-way videotex operational 
model is based on the concept of a consumer and an information 
provider or service operator. Because of this asymmetry, it is 
assumed that almost all graphical information will flow from the 
provider toward the consumer. In the reverse direction, the 
consumer is expected to manipulate and transmit alphanumeric 
information, for the most part. Although this standard includes 
geometric drawing primitives, a user cannot directly modify shapes 
drawn with the primitives. 


At present, NAPLPS does not include interaction concepts like 
picture transformations or detectability, which are fundamental 
for attaining a shared graphical workspace. Neither does it allow 
key graphics input devices like mice, joysticks, stylus, rotating 
balls, or light pens, which are needed for simple and efficient 
editing of the shared workspace. 


We want to have user-to-user graphical communication that features 
the level of sophistication and ease of interaction provided by 
today’s interactive graphics packages. Computer vector graphics 
can provide both because its paradigm includes an application 
program that keeps track of a very large number of possible 
changes of state of the displayed picture. In addition, the 
application drives a powerful graphics package, like GKS or ACM 
Core. In the videotex paradigm, the provider application only 
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allows limited changes to the displayed image, primarily database 
retrieval requests. Also, the paradigm does not include a separate 
graphics package. Both the graphics functionality and the data 
format are collapsed into a coding specification, like NAPLPS. 


In this paper we are interested primarily in business and 
industrial applications where there is a two-way, or multi-way, 
flow of vector graphics information among the users. The users 
will have workstations with substantial processing and storage 
capacities, and high-resolution monitors; moreover, the 
communication will be on a distributed architecture not depending 
on a central server host, like the provider application host of 
videotex. 


Currently, the videotex equipment at the consumer end consists of 
inexpensive microprocessor-based decoders or personal computer 
boards driving, in most cases, low-resolution standard TV sets and 
personal computer displays. There is already affordable technology 
to produce sophisticated decoders and high-resolution graphics 
devices. The videotex standards need extensive revisions to take 
advantage of these advances; in particular, they should consider 
the receiving devices as capable of hosting a programmable 
customer-application process. When this happens, videotex 
protocols will be applicable to our intended problem areas [8]. 


The Computer Graphics Metafile [9] will become an international 
and North American standard for graphics picture interchange in 
the near future. However, the CGM, also referred as VDM, is a 
picture-capture metafile that only records the final result of a 
graphics session. It is not intended to record the 
picture-creation process, which is fundamental for the interactive 
applications that we are addressing. Moreover, the CGM is 
presently aimed at a minimum support of GKS functionality. It will 
be some time before the CGM will have some of the elements needed 
for on-line interaction. If, after these additions, the CGM is 
augmented for session capture, it would become a logical candidate 
for a protocol format. 


Another future standard is the Computer Graphics Interface, CGI 
also referred as VDI [10]. The CGI is a standard functional and 
syntactical specification of the control and data exchange between 
device-independent graphics software and one or more 
device-dependent graphics device drivers. A major use of the CGI 
is for the communication between an application host anda 
graphics device, but the asymmetry between its intended 
communicating ends hinders the use of CGI for our purposes. 


Aguilar [Page 5] 


RFC 965 December 1985 
A Format for a Graphical Communication Protocol 


II. 


As previously stated, we want to take advantage of intelligence 
and storage at the communicating ends in order to achieve powerful 
information-conveying effects using narrow-bandwidth channels. 
This requires that the format we seek must have items for 
communication between two applications. In contrast, the CGI 
streams are processed by device-dependent drivers, rather than by 
applications. The CGI specification does include application data 
elements, but only to be stored in a metafile. These application 
data elements are not interpreted by the drivers, but by 
applications that read the metafile, some time after metafile 
creation. 


Furthermore, the CGI has elements for obtaining graphical input, 
as well as elements for inquiring graphics device capabilities, 
characteristics, and states. Later, in Section III, we explain why 
these two classes of elements are unnecessary for the 
communication protocol we need. As the CGI evolves, it will 
undergo significant changes, and, in the future, it may become a 
very suitable kernel for the graphics protocol we seek. Asa 
matter of fact, the CGI will be the communication protocol between 
graphical application hosts and graphics terminals. At SRI we are 
tracking its evolution, and we are interested in defining a format 
based on the CGI. 


Finally, the Initial Graphics Exchange Specification [11] is not 
aimed at our primary area of interest. The IGES defines standard 
file and language formats for storing and transmitting 
product-definition data that can be used, in part, to generate 
engineering drawings and other graphical representations of 
engineering products. Besides the CAD orientation of IGES, the 
graphical output function may be secondary to other goals like 
transmitting numerical-control machine instructions. 


OPERATIONAL REQUIREMENTS AND USABILITY 


The main goal of this paper is to lay the groundwork for the 
development of a vector graphics format to be used as a basis for an 
on-line graphical communication protocol. We call such a format an 
"interactive graphical communication format," or IGCF. In this 
section we describe some operational requirements and usable 
characteristics for an IGCF. 


Interoperation of Heterogeneous Systems 


A first functional requirement is that an IGCF must permit 
communication among heterogeneous graphical systems differing both 
in the hardware used and in the software of their graphics 
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application interfaces. This is a fundamental for attaining 
communication among similar graphical application programs running 
on dissimilar hardware and using dissimilar graphics interface 
packages. Some examples of such application programs are graphics 
editors, CAD systems, and graphical database retrieval programs 
communicating with other editors, CAD programs, and graphical 
databases, respectively. 


B. Picture Capture 


A required characteristic of an IGCF is that it must be usable for 
the exchange of static graphic pictures, i.e. for picture capture; 
yet, it must not be restricted to final picture recording only. 
There will be picture exchanges as part of the interactive 
communication, and we anticipate the need to record the state of a 
picture at some points during the on-line graphics engagement. We 
foresee the creation of graphical IGCF libraries containing object 
definitions and pictures for inclusion in new pictures. Since 
metafiles have been used for a long time to capture pictures, 
there is a strong motivation to base an IGCF on a metafile 
standard in order to secure compatibility with a large number of 
metafile sources and consumers. 


C. Prompt Transmission 


In some forms of interactive graphical communication, like 
audiographics conferencing, it is critical to convey across users 
the real-time nature of the interaction. This dictates that object 
creations and manipulations be transmitted as they happen rather 
than as a final result since a substantial part of the information 
may be transmitted concurrently with the construction or operation 
of an object, possibly through associated media like voice. Since 
both construction and manipulation processes have to be 
transmitted, there is a limit to the number of intermediate states 
that can be economically transmitted. 


A third requirement is, therefore, that the IGCF elements provide 
fine "granularity" to convey the dynamics of the constructions and 
manipulations. We believe that it is sufficient that the IGCF have 
basic construction elements like polygons, markers, polylines, and 
text strings and that it transmit them only when they are 
completed; i.e., it is not necessary to transmit partial 
constructions of such elements. 


The problem for manipulations extends beyond an IGCF. Whereas we 


know that an IGCF should include segment transformations, segment 
highlighting and segment visibility on/off, the transmitter must 
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decide how often to sample an on-going transformation and transmit 
its current state. The choice of a sampling frequency will depend 
on the available transmission bandwidth. 


D. Low Traffic Volume 


In many of the applications we envision, coordinate graphics will 
be transmitted over narrow bandwidth channels, and thus it is 
essential to minimize traffic. Accordingly, several requirements 
are imposed on an IGCF to take advantage of the characteristics of 
the graphics communication intercourse and architecture in order 
to minimize traffic. 


An IGCF can help reduce traffic by including the basic geometric 
objects from which so many other objects are built. Moreover, an 
IGCF should permit the use of objects for the creation of more 
complex objects; since reuse is very common, the result is a 
reduction of traffic and storage cost. 


E. Preservation of Application Semantic Units 


A related requirement is that an IGCF must include elements to 
represent graphical objects corresponding to real world entities 
of the intended applications. For example, in a Navy application, 
the entities of interest are carriers, submarines, planes, and the 
like. We want to communicate such semantic units across systems 
and to treat them as unitary objects because, in many 
applications, communication is based on creating and operating 
such units. If an IGCF has elements to represent such semantic 
units, the communication traffic decreases because the entity 
definitions can be transmitted only once and then reused, and 
because the entities are manipulated as units rather than 
separately manipulating their components. 


It turns out that there is a small set of primary operations that 
can be applied to a graphical object, and an IGCF must have 
elements representing such operations. In contrast to dumb 
graphics terminals receiving screen refresh information from a 
host, we foresee graphical communication taking place among 
intelligent workstations that can exchange encoded operations, 
interpret them, and apply them to objects stored locally. 


F. Transmission Batching 
We previously indicated the desirability of conveying to the human 


users the real-time tempo of interactive graphics exchanges. 
However, it is possible to do so without having to transmit 
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immediately all IGCF elements. As a matter of fact, IGCF elements 
should be divided into those causing a change on a displayed 
picture and those that do not, although both classes may cause 
changes to the stored graphical data structures. 


It is only necessary to transmit immediately those elements 
causing a visible change on a displayed picture because they are 
the ones whose reception and interpretation delivers information 
to a human user. The second class of elements can be batched and 
queued for transmission until one element of the first class is 
submitted. We call the first class update Group-l, and the second, 
update Group-2. 


The aforesaid division is quite important for packet 
communications because each packet contains a hefty amount of 
overhead control traffic. It is therefore mandatory to batch, into 
a packet, as much client data as possible in order to reduce total 
traffic. The batching units can be varied in size according to the 
network traffic and response time of conference hosts. During 
congested periods, the units may have to be increased, thus 
lowering the number of messages, and then reduced when congestion 
eases, thus increasing the number of messages. 


G. Simple Translation Between IGCF and User Interface 


According to the first requirement, an IGCF must permit the 
interoperation of related heterogeneous graphics applications. 
Such interoperation has, as an objective, the communication 
between human users or between a human and a database. 
Correspondingly, the interoperation involves a mapping between the 
user interface commands and the IGCF elements. It is not advisable 
to use the commands themselves as the IGCF elements; otherwise the 
exchange would depend on the communicating systems, and every pair 
of communicating systems would require an ad-hoc protocol. 


An additional usability characteristic is that there must be a 
simple mapping between IGCF elements and the actions represented 
by the user interface commands employed for graphical 
communications. This simplicity is a must because every 
communicating graphical system must have a translator that ideally 
should be very simple. It seems that the inclusion of command 
sequence delimiters in the IGCF helps the simplicity since the 
delimiters permit keeping a smaller amount of state information 
for processing an IGCF stream. 


We have verified the mapping from one set of commands for 
audiographics conferencing to the IGCF proposed in this paper. The 
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III. 


mapping from user interface commands to IGCF can be done in a 
direct and efficient manner; on the other hand, the reverse 
mapping, from IGCF to user interface commands, is a more difficult 
task. We anticipate that, in order to improve performance, we will 
have to map the IGCF elements to calls to lower level subroutines 
implementing the user interface actions. Whereas such mapping is 
conceptually no more complex than translating IGCF to the commands 
themselves, it will require considerably more programming. 


ELEMENTS OF AN IGCF 


IGCF Element Classes 


In this section we list the classes of elements that we believe an 
IGCF should have in order to exchange vector graphics under the 
requirements of the previous section. The classes correspond to 
the common function classes in computer graphics interfaces, and 
each contains elements corresponding to interface primitives and 
attributes. We do not list the elements for each class because 
they are exemplified by the elements in the proposed IGCF. 


In the following list, two categories of functions are missing: 
functions used to query the status of a graphics system, and input 
functions. As a matter of fact, an IGCF only needs to have 
elements representing actions that cause a change in the state of 
the communicating graphical systems, and the inquire functions 
obviously do not change their state. Even though an input function 
executed at the transmitting end causes a local change, it is not 
necessary to transmit the input command itself. The receivers only 
need to get the data input, in IGCF representation, and they can 
process the data in any manner, maybe simulating local input 
actions. 


Control 
Elements for workstation: initialization, control and 
transformation; and elements for normalization transformation. 
(The normalization and workstation transformations can be used 
to implement zooming.) 

Primitive attributes 
Elements for primitive, segment, and workstation attributes. 


Output primitives 


Elements for output primitives. 
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Segmentation 


Elements for basic segmentation and workstation independent 
segment storage. 


Object manipulations can be implemented with segment 
transformations. Object insertion can be implemented using 
segment recall and segment visibility. Object deletion can be 
implemented using segment deletion and segment visibility. 
Object selection can use segment highlighting as feedback to 
the user. 


Dynamics 


A considerable part of the graphical information exchanged 
through an IGCF will be in the form of pointer movements over a 
background picture. Pointer tracking is used to transmit points 
sampled from a graphical pointer trace in order to reproduce, 
at the receivers, the movement of the pointer at the sender 
site. This can be done either by just moving the cursor or by 
tracing its movement with a line. Rubber band echoes are used 
to signal areas, routes, and scopes in a highly dynamic way. 
These are indicated by an echo reference point and a feedback 
point. 


Hierarchical object definitions 


The requirement for preserving application semantics dictated that 
an IGCF include the means to represent objects that stand for 
application entities, and to manipulate such entities as graphical 
units. Furthermore, the low-traffic-volume requirement called for 
the use of already existing objects for the creation of new ones. 


One way to meet the aforesaid requirements is by including in an 
IGCF the means to represent object hierarchies. In such a 
hierarchy an object is a set of output primitives associated with 
a set of attribute values or a set of lower-level objects, each 
associated with a composition of transformations [12]. 


Graphics segments can be used to implement objects in the lowest 
level of a hierarchy. The definition of a higher-level object can 
be represented by sequences of IGCF elements describing the 
definition process. Such a definition can be done by instantiating 
lower-level objects with specific transformation parameters. Thus 
an IGCF must incorporate brackets to mark the beginning and end of 
object definitions, object instantiations, and object 
redefinitions. 
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In order to complement the mechanism for object definition, an 
IGCF must permit the use of a flexible alphabet for creating 
object identifiers that ensure the uniqueness of an identifier in 
a hierarchy. The construction of the object identifiers is not 
part of an IGCF, an IGCF only has to represent the identifiers. 
Further, an identifier has to be independent of a communication 
session and a particular graphics system so that identifiers 
created at a host during one session can be used, in other 
sessions possibly involving other hosts, to recall the objects 
they label. 


We also leave to the communicating systems the implementation of 
mechanisms to resolve duplicate identifiers when merging two 
hierarchies, created in different sessions. In this paper we shall 
limit ourselves to the warning that segment numbers do not qualify 
as identifiers because they depend on the session and state of the 
system in which they are created. 


In addition to object definition and instantiation, an IGCF should 
have elements representing operations on objects. The operations 
so far identified are: transformation, deletion, display, 
disappearance, expose, and hide. Expose is used to uncover objects 
on a screen that are hidden by other objects; hide is used to 
place an object behind others on a screen. 


IV. A PROPOSED IGCF 
A. Using the GKSM as a Basis 


An IGCF must be usable to transmit all graphical actions ina 
conference session. This suggests to base an IGCF on a standard 
session-capture graphics metafile, thus ensuring compatibility 
with a large user population. We have based the proposed IGCF, 
PIGCF, on the GKSM session-capture metafile specification because 
GKSM contains many of the elements identified for an IGCF [14]. In 
addition, the audit trail orientation of GKSM permits the 
recording of interactive communication sessions for later play 
out, and this is a feature that we anticipate will be frequently 
used. 


The GKSM is a proper subset of our PIGCF and thus any graphical 
system developed to handle the PIGCF, can read a GKSM metafile. 
Conversely, the applications using the PIGCF should have an option 
for constraining session recording only to the GKSM part, possibly 
suppressing some session events. By doing so, we will be able to 
ship a GKSM metafile to any correspondent who has GKSM 
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interpretation software. Alternatively, an application with a 
GKSM interpreter but without an PIGCF interpreter can read a PIGCF 
file interpreting only the GKSM part and ignoring the rest. 


Whereas the GKSM was specified for the GKS system, we believe that 
the GKSM is a sound and general basis for all of our 2-D 
applications. We feel that the GKSM specification is not parochial 
to GKS systems but contains all the most useful items desired in a 
metafile. In the future, we expect to tackle applications 
requiring 3-D, like interactive repair and maintenance aids. When 
GKS be augmented with 3-D capabilities [13], we will extend the 
PIGCF with any necessary elements. 


We are aware that the GKSM specification is not part of the GKS 
standard itself but is an appendix recommending such a metafile 
format. Nevertheless, all the GKS vendor implementations that we 
know of, at the present time, support GKSM metafile output and 
interpretation. If this trend continues, as we expect, we will be 
able to exchange graphical files with a large base of GKS 
installations. There will indeed be many of them since GKS will be 
adopted as an standard by ISO and by many national standard bodies 
in the near future. 


B. Positional Information Coordinates 


Following the GKSM convention, the PIGCF positional information is 
in normalized device coordinates, NDC. Thus the originator of a 
conference must indicate the workstation window for the 
conference. This window is the sub-rectangle of the NDC space 
enclosing the area of interest for the conference. In most cases, 
the participating workstations will take this window as their own. 
However, the graphical systems should provide for the possibility 
of a workstation choosing a different workstation window, which 
may contain the conference window or just overlap it. Except for 
special cases, a conference originator should not state a 
conference workstation viewport. In this manner, each workstation 
can display its workstation viewport in the most convenient 
portion of the screen. 


There will be conferences where the participating workstations 
will maintain the positional information in world coordinates, WC. 
It might be necessary to reconstruct the world dimensions after 
transmission because such dimensions have a relevant meaning for 
the application, like sizes of components or distances. In this 
case, a workstation will have to map from WC to NDC before 
transmitting and from NDC to WC after receiving. At the outset, 
the conference originator has to specify the world window and the 
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NDC viewport used in the conference in order for the conferencing 
workstations to do such mappings. These mappings could be done by 
the presentation layer, in terms of the ISO Open Systems 
Interconnection Reference Model, in a manner that is transparent 
to the communicating application programs. 


Most often all workstations will have the same world windows and 
NDC viewports. However, the graphical systems will provide for the 
possibility of a workstation choosing a different window or 
viewport, but such workstation will have to record the conference 
ones for doing the aforesaid mappings. There are graphical 
systems, like the ACM Core, that do not provide for a workstation 
transformation. In such systems, the NDC viewport is considered to 
be the workstation window for the aforesaid mappings. 


C. Layers of the PIGCF 


There are two levels in the PIGCF a lower level L and an upper one 
U. The lower level L is just the GKSM metafile specification as 
defined in Appendix E of the proposed GKS ANSI standard [14]. We 
have excerpted most of Appendix E of [14] at the end of this RFC 
as our Appendix A. All level L elements belong to the update 
Group-1 except: SET DEFERRAL STATE, the output primitive attribute 
elements, the workstation attribute elements, CLIPPING RECTANGLE, 
CREATE SEGMENT, CLOSE SEGMENT, RENAME SEGMENT, SET SEGMENT 
PRIORITY, and SET DETECTABILITY. 


The upper level U is those elements that we believe complement the 
GKSM for general on-line graphical exchanges. This layering 
conforms to the graphics metafile level-structure described in 
Enderle et. al [15]. Under such structuring, an application 
oriented metafile can be based on graphical metafiles. 


D. PIGCF Elements in the Level U 


The level U items are encoded as GKSM user item elements so that a 
PIGCF file will conform to the GKSM metafile specification. 
Accordingly, a PIGCF file will be a GKSM metafile in its entirety. 
We use the same formatting conventions as the GKSM specification. 
Those unfamiliar with these conventions should read the beginning 
of the appendix. The following items belong to the second update 
group: the two items for object definition, the two items for 
object redefinition, the two items for object instantiation, the 
two items for normalization transformation, SELECT COMPONENT, and 
RECALL LIBRARY. The remaining items belong to the first update 
group. 
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Items for Object Definition 

BEGIN DEFINITION 
| ’GKSM 120” | L | 
Indicates beginning of object definition sequence 

END DEFINITION 
| ’GkKsM 121” | L | F| 
Indicates end of object definition sequence. I(Nc): object 
identifier ( N preceding c, i, r means an arbitrary number 
of characters, integers, or reals.) Objects defined 
interactively are made visible on the screen; i.e. they are 


automatically instantiated. If only the definition is to be 
kept but not the image, a DISAPPEAR item must follow. 


BEGIN REDEFINITION 
| ’GKSM 122” | L | I | 


Indicates beginning of object redefinition sequence 
I(Nc): object identifier 


END REDEFINITION 
| ’GKSM 123” | L | 
Indicates end of object redefinition sequence 
Items for Object Instantiation 
BEGIN INSTANTIATION 
| ’GKSM 124” | L | I | 


Indicates beginning of object instantiation sequence 
I(Nc): Object identifier 


END INSTANTIATION 
| ’GKSM 125” | L | 


Indicates end of object instantiation sequence 
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Items for Object Manipulation 
TRANSFORM OBJECT 
| ’GksM 126: | L | c |[ IT | M | 
Apply transformation M to object I 
C: number of characters in identifier 
I(Nc): object id 
M(6r): upper and center rows of a 3x3 matrix representing 
a 2D homogeneous transformation [12]. 
M 11 M 12 M 13M 21 M 22 M 23 
DELETE OBJECT 
| ’GKSM 127” | L | I | 
I(Nc): object identifier 
DISPLAY OBJECT 


| ’GKsM 128” | L | I | 


Turn on visibility of object I 
I(Nc): object identifier 


DISAPPEAR OBJECT 
| ’Gksm 129” | L | 1 | 


Turn off visibility of object I 
I(Nc): object identifier 


EXPOSE OBJECT 
| ‘GKSM 130” | L | I | 


Redisplay object I on top of any overlapping objects 
I(c): object identifier 


HIDE OBJECT 
| /GKSM 131” | L | F| 


Redisplay object I behind any overlapping objects 
I(c): object identifier 
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SELECT COMPONENT 
| ’GK%M 137 |L | “TP | 
Select component P of object I 
I(c): object identifier 
P(i): pick id of component 
This is used to select a group of output primitives 
identified by P in a segment associated with I. 

ERASE COMPONENT 
| ‘GKSM 133’ | L | I | P | 
Erase component P of object I 
I(c): object identifier 
P(i): pick id of component 
This erases a group of output primitives identified by P in 
a segment associated with I. This element can be used only 
within a REDEFINE OBJECT sequence. 

Items for Normalization Transformation 
SET WINDOW 
"GKSM 134” | L | W | 

Define boundaries of world window for normalization 
transformation. 
W(4r): limits of world window (XMIN, XMAX, YMIN, YMAX ) 

SET VIEWPORT 

'GKSM 135’ | L | v | 

Define boundaries of NDC viewport for normalization 


transformation. 
V(4r): limits of NDC viewport (XMIN, XMAX, YMIN, YMAX ) 
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Items for Other Operations 
ABORT 
| ’GKSM 136” | L | 
Abort ongoing operation transmitted in PIGCF stream. This 
provides the means to abort unwanted or erroneous 
operations. Only the innermost operation of a nested 
sequence is aborted; successive aborts can be used to get 
out of several levels of operation nesting. 
POINTER TRACKING 


| ““EKSMAAZIA |L [r | ee | 


Update graphical pointer position to P 


T(i): 0 causes only cursor to be moved 
1 causes cursor movement to be traced with 
a line 

P(p): a point sampled from graphical pointer 


movement trace 
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RUBBER BAND 
| ’GksM 138’ | L | T | P | 


Echo a rubber band of type T with given reference and 
feedback points. The first occurrence of this item ina 
sequence carries the coordinates of the echo reference 
point. Subsequent occurrences carry updates to a pointer 
position indicating an echo feedback point. 


T(i): echo type 
( 0 echo reference point; 
> 0 echo feedback: 


1 = line, 
2 = rectangle, 
3 = circle ) 
P(r): echo reference point (T = 0), 


or echo feedback point (T > 0) 


The reference and feedback points are: 


T = 1 - reference is one end of line, feedback is 
other end. 

T = 2 - reference is one corner of rectangle, feedback 
is opposite corner. 

T = 3 - reference is center of circle, feedback is 


perimeter point. 
RECALL LIBRARY 
| ’GKSM 139” | L | F | 


Recall graphical library in file F 
F(i): name of file containing library 


The graphical pictures in F and all their components become 
available for use during the communication session. The 
pictures are assumed to be recorded with the PIGCF, and 
their components have to be displayed with DISPLAY OBJECT 
elements or similar actions so that the pictures become 
visible. 
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V. 


AN ARCHITECTURE FOR PIGCF PROCESSING 


This section presents an example software architecture for the 
generation and interpretation of PIGCF in a multimedia conferencing 
system using GKS as the underlying programmer's graphics interface. 
This section should not be interpreted as a definitive statement of 
such an architecture, but only as an exercise to illustrate how the 
format proposed in this paper fits within the overall framework of a 
conferencing system. Choosing GKS simplifies the example 
architecture; nevertheless, other graphics packages can be used by 
adding, to the architecture, the modules to interpret and generate 
the PIGCF level L items. 


Figure 1 shows the major software modules charged with graphics 
interaction and display at a conferencing workstation. This is a 
familiar programmer's view of the graphics pipeline. A conferencing 
application program updates data structures and uses 
device-independent graphics services through a language binding. 
These services, in turn, use device-dependent graphics services that 
call on device drivers to accept input and to present graphic 
pictures. The application performs numerous other functions for 
conference management and control of other media streams, but we need 
not consider them in this example. 


In Figure 2, the basic graphics pipeline has been augmented with the 
software modules involved in the generation, transmission, reception, 
and interpretation of PIGCF streams. The application has a module for 
interpreting the lower and higher levels of PIGCF and one for 
generating the upper level U. The device-independent graphics 
services include modules for generating and interpreting the lower 
level, L. This reflects the current practice of including the 
generation and interpretation functions in the graphics package. 
There is also a module that transmits the outgoing PIGCF streams to 
remote work stations. Similarly, there is a module that receives 
incoming streams from remote stations. In actual practice, the 
transmit and receive modules are decomposed into several processes 
implementing a layered protocol architecture. A process receives both 
levels of PIGCF and writes them into a conference record metafile for 
future use. A router process receives and forwards PIGCF traffic from 
and to the modules previously referred. This router is likely to be 
replaced by independent communication interfaces between pairs of 
modules exchanging PIGCF. 


The thick arrows show the flow of outgoing PIGCF, whereas the thin 
arrows show the incoming PIGCF flow. We first follow the outgoing 
path, starting at the application. The application processes local 
user actions which are transformed into data structure updates, level 
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U PIGCF elements, and executions of device independent graphics 
subroutines that, among other things, generate level L PIGCF (GKSM) 
elements. 


The router merges both level streams according to generation order 
and sends them to the local copy of the conference record and to the 
transmission module. The latter batches Group-2 PIGCF items until it 
receives a Group-l item. It also timestamps the PIGCF stream to 
synchronize its play-back, at the receiver, with the play-back of 
other media information. The PIGCF may be separated into traffic 
categories transmitted over diverse communication facilities 
according to the transport services required by the categories, for 
example, real-time service for pointer updates, highly reliable 
transmission for new object definitions, or low-priority service for 
graphical library transfers. Finally, the transmit module must 
acknowledge the reception of incoming PIGCF, and of other media 
traffic as well. 


The receive module is the entry point for incoming PIGCF streams that 
may come within diverse traffic categories requiring merging. It 
checks the timestamps for synchronizing PIGCF items with related data 
in other media, for example, voice. It is possible to include here a 
high-level error-correction function that validates the received 
streams using state and context information about PIGCF syntax and 
semantics. The receive module passes the streams to the router which 
forwards them to three processes: It sends level L items to the GKSM 
interpreter which produces the corresponding changes on the displayed 
picture; it sends level L and level U items to the conference record, 
as well as to the PIGCF interpretation code in the application. The 
level U items cause updates to both the data structures modeling 
object hierarchies, and the pictorial representation of the 
hierarchies, through the execution of graphics services. U items also 
update graphics cursors and may recall new graphics libraries. The 
application must process level L items because they could indicate 
updates to the data structures; this happens if, for example, the 
structures record attribute value information for the object 
hierarchies. The application coordinates these actions with other 
media effects according to the timestamps. Conference record 
play-back is done in off-line mode. Record items are received by the 
router and thereafter processed similarly to incoming PIGCF. 
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4+------------ + 4+------------- + 
|APPLICATION | | OTHER | 
| DATA | | MEDIA | 
| STRUCTURES | |------------- | 
+----- |------ + | CONFERENCE | 
|---------- > | APPLICATION | 
GRAPHICS 
|---------- > | | 
t----—|------+ | | 
| LANGUAGE | +------------—- + 
| BINDING | 
+----- |------ + +------------- + 
| ---------- > DEVICE- 
+------------ + INDEPENDENT 
| DEVICE | | GRAPHICS | 
| DEPENDENT | <---> | SERVICES | 
| GRAPHICS | | | 
| SERVICES | | | 
= | 
v | | 
+-----------—- + | | 
| DEVICE | | | 
| DRIVERS | | | 
+------------ + 4+------------- + 


FIGURE 1 - THE BASIC GRAPHICS PIPELINE 
IN A CONFERENCING SYSTEM 
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4+------------ + 4+------------ + 4+------------------ + 
|APPLICATION | | OTHER | | TRANSMIT 
| DATA | | MEDIA | | ACK |=> 
| STRUCTURES | |------------ | +----- + | SEPARATE TRAFFIC |=> 
+----- |------ + | CONFERENCE | | [===> BATCHING |=> 
| ---------- > | APPLICATION | | | | TIMESTAMPING | 
GRAPHICS +---------------—-- + 
— > |-----=------ bo po 
| | PIGCF L, U | <---| | +------------------ + 
+----- | ------ | | INTERPRETER | | | | RECEIVE | 
| LANGUAGE ć | +------------ + | R | | MERGE TRAFFIC |<- 
| BINDING | | PIGCF U |===> | o | <---| CHECK TIMESTAMPS |<- 
+----- | ------ + | GENERATOR | | U | ERROR CORRECTION |<- 
4------------ + T 
-----------------—-— | E | +------------------+ 
+-----------—- + +----—- V------ + | R | 
| DEVICE | | DEVICE | | | +------------------ + 
| DEPENDENT | | INDEPENDENT | | |====> | 
GRAPHICS <-->| GRAPHICS pres CONFERENCE | 
| SERVICES SERVICES | RECORD 
| | | | | | | | 
wen Fe E | | | aa ae aca MÈ + 
| | GKSM | | | 
v | INTERPRETER|<--- | | <--- INCOMING PIGCF 
4+------------ + 4+------------ + 
| DEVICE | | GKSM | | | ===> OUTGOING PIGCF 
| DRIVERS | | GENERATOR |===> | | 
+------------ + +------------ + 4+----- + 


FIGURE 2 - A CONFERENCING SOFTWARE ARCHITECTURE FOR PROCESSING PIGCF 
VI. CONCLUSIONS 


Teleconferencing and other multi-media applications will be part of 
the communication resources available to organizations in the near 
future. This will prompt computer graphics and computer communication 
practitioners to address the issue of application-to-application 
graphics communication. A key element of the issue is a protocol, and 
a key component of the protocol is a data format. We have presented 
the operational requirements for such a protocol and have proposed a 
format that fulfills these requirements. 


At present, none of the existing or emerging graphics standards can 
be used as the needed protocol or as a format for the protocol, but 
this may change as the standards evolve. We are monitoring the 
standards development and will study the use of some of them as a 
format basis, in particular the CGI. Nevertheless, the computer 
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communication community badly needs experience with multi-media 
conferencing implementations. In order for these applications to 
happen, one can base a graphics communication protocol on an official 
or on a de-facto standard that is likely to gain wide use thus 
assuring interoperability with a broad user base. We believe that, 
by using the GKSM session metafile, we are moving in the proper 
direction. 


Planning the software architecture for generating and interpreting 
the proposed PIGCF has brought up some problems we will confront as 
we continue our work toward the development of a complete graphics 
protocol. This is being done as part of the SRI on-going program in 
multimedia communications. Within this program, we are implementing 
a simple multi-media conferencing prototype and will design a more 
complete one. The experience from both exercises will be a valuable 
input to the protocol architecture design. 
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APPENDIX A 
Excerpt from "Draft Proposal: Graphical Kernel System" [14] 
E.2 Metafile Based on ISO DIS7942 


This metafile may be categorized as one which aims to provide a 
means of recording the exact sequence of function calls made to 
GKS. Its functional capability covers the entire range of GKS 
output functions, from level m to level 2. It is, therefore, 
suitable for applications where the individual graphics actions 
need to be “played back’, perhaps with selective graphical editing 
being done by the interpreter. 


Two encodings have been specified for this metafile. One encoding 
is inefficient for many applications. The second allows an 
unspecified binary format. The remainder of this IGCF appendix 
gives full details of these metafile structures and encodings. 


E.2.1 File Format and Data Format 


The GKS metafile is built up as a sequence of logical data 
items. The file starts with a file header in fixed format which 
describes the origin of the metafile (author, installation), 
the format of the following items, and the number 
representation. The file ends with an end item indicating the 
logical end of the file. In between these two items, the 
following information is recorded in the sense of an audit 


trail: 

a) workstation control items and message items; 

b) output primitive items, describing elementary 
graphics objects; 

c) attribute information, including output primitive 
attributes; segment attributes, and workstation 
attributes; 

d) segment items, describing the segment structure and 
dynamic segment manipulations; 

e) user items. 


Aguilar [Page 25] 


RFC 965 


December 1985 


A Format for a Graphical Communication Protocol 


Aguilar 


The overall structure of the GKS metafile is as follows: 


FILE: |file |item|---|item|---|end | 
|header| 1 | a. iil |item] 
ITEM: item item data record 
header 
ITEM |'GKSM”  |identification]|length of item data| 
HEADER: |optional| number | in bytes 


All data items except the file header have an item header 
containing: 


a) the character string ’GKSM’ (optional) which is 
present to improve legibility of the file and to 
provide an error control facility; 


b) the item type identification number which indicates 
the kind of information that is contained in the 
item; 

c) the length of the item data record. 


The lengths of these fields of the item header are 
implementation dependent and are specified in the file header. 
The content of the item data record is fully described below 
for each item type. 


The metafile contains characters, integer numbers, and real 
numbers marked (c), (i), (r) in the item description. 
Characters in the metafile are represented according to ISO 646 
and ISO 2022. Numbers will be represented according to ISO 6093 
using format F1 for integers and format F2 for reals. (Remark: 
Formats F1 and F2 can be written and read via FORTRAN formats I 
and F respectively.) 


Real numbers describing coordinates and length units are stored 
as normalized device coordinates. The workstation 
transformation, if specified in the application program for a 
workstation writing a metafile of this format, is not performed 
but WORKSTATION WINDOW and WORKSTATION VIEWPORT are stored in 
data items for later usage. Real numbers may be stored as 
integers. In this case transformation parameters are specified 
in the file header to allow proper transformation of integers 
into normalized device coordinates. 
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For reasons of economy, numbers can be stored using an internal 
binary format. As no standard exists for binary number 
representation, this format limits the portability of the 
metafile. The specification of such a binary number 
representation is outside the scope of this document. 


When exchanging metafiles between different installations, the 
physical structure of data sets on specific storage media 
should be standardized. Such a definition is outside the scope 
of this standard. 


E.3 Generation of Metafiles 


Table El contains a list, by class, of all GKS functions which 
apply to workstations of category MO, and their effects on this 
GKSM. In the table, GKSM-OUT is a workstation identifier 
indicating a workstation writing a metafile of this format. 


The concepts of clipping rectangle and clipping indicator are 
encapsulated in one metafile item which specifies a clipping 
rectangle. This item is written to the metafile on activate 
workstation with the values (0, 1, 0, 1), if the clipping 
indicator is OFF, or the viewport of the current normalization 
transformation, if the clipping indicator is ON. If the viewport 
of the current normalization transformation is redefined or a 
different normalization transformation is selected when the 
clipping indicator is ON, a further clipping rectangle item is 
written. If the clipping indicator is changed to OFF, a clipping 
rectangle item (0, 1, 0, 1) is written. If the clipping indicator 
is changed to ON, an item containing the viewport of the current 
normalization transformation is written. This is analogous to the 
handling of clipping in segments (see 4.7.6 [14]). 


GKS functions which apply to workstations GKSM item created 
of category MO or effect 


Control functions 


OPEN WORKSTATION (GKSM-OUT,...) file header) 


Fen 

1 (CONDITIONAL) 
CLOSE WORKSTATION (GKSM-OUT) 0 (end item) 
ACTIVATE WORKSTATION (GKSM-OUT) (61, 21-44) 

ensure attributes 

current; 


enable output 
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DEACTIVATE WORKSTATION (GKSM-OUT) disable output 
CLEAR WORKSTATION (GKSM-OUT,...) di 
2 


REDRAW ALL SEGMENTS ON WORKSTATION (GKSM-OUT) 


UPDATE WORKSTATION (GKSM-OUT,...) 3 
SET DEFERRAL STATE (GKSM-OUT,...) 4 
MESSAGE (GKSM-OUT,...) 5 (message) 
ESCAPE 6 
Output Primitives 

POLYLINE 14. 
POLYMARKER 12 
TEXT 13 
FILL AREA 14 
CELL ARRAY 15 
GENERALIZED DRAWING PRIMITIVE 16 
Output Attributes 

SET POLYLINE INDEX 2: 
SET LINETYPE 22 
SET LINEWIDTH SCALE FACTOR 23 
SET POLYLINE COLOUR INDEX 24 
SET POLYMARKER INDEX 25 
SET MARKER TYPE 26 
SET MARKER SIZE SCALE FACTOR 27 
SET POLYMARKER COLOUR INDEX 28 
SET TEXT INDEX 29 
SET TEXT FONT AND PRECISION 30 
SET CHARACTER EXPANSION FACTOR 31 
SET CHARACTER SPACING 32 
SET TEXT COLOUR INDEX 33 
SET CHARACTER HEIGHT 34 
SET CHARACTER UP VECTOR 34 
SET TEXT PATH 35 
SET TEXT ALIGNMENT 36 
SET FILL AREA INDEX 37 
SET FILL AREA INTERIOR STYLE 38 
SET FILL AREA STYLE INDEX 39 
SET FILL AREA COLOUR INDEX 40 
SET PATTERN SIZE 41 
SET PATTERN REFERENCE POINT 42 
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SET ASPECT SOURCE FLAGS 43 

SET PICK IDENTIFIER 44 

Workstation Attributes 

SET POLYLINE REPRESENTATION (GKSM-OUT,...) 51 

SET POLYMARKER REPRESENTATION (GKSM-OUT,...) 52 

SET TEXT REPRESENTATION (GKSM-OUT,...) 53 

SET FILL AREA REPRESENTATION (GKSM-OUT,...) 54 

SET PATTERN REPRESENTATION (GKSM-OUT,...) 55 

SET COLOUR REPRESENTATION (GKSM-OUT,...) 56 
Transformation Functions 

SET WINDOW of current normalization 34, 41, 42 
transformation 

SET VIEWPOINT of current normalization 61, 34, 41, 42 
transformation 

SELECT NORMALIZATION TRANSFORMATION 61, 34, 41, 42 
SET CLIPPING INDICATOR 61 

SET WORKSTATION WINDOW (GKSM-OUT,...) 71 

SET WORKSTATION WINDOW VIEWPORT (GKSM-OUT,...) 72 


Note: item 61 


Note: 


(CLIPPING RECTANGLE) 


When the current normalization transformation is altered, 


is described more fully in E.2.2. 


items 


corresponding to attributes containing coordinate information are sent 


(items 34, 41, and 42). 


Segment Functions 


CREATE SEGMENT 81 

CLOSE SEGMENT 82 

RENAME SEGMENT 83 

DELETE SEGMENT 84 

DELETE SEGMENT FROM WORKSTATION (GKSM-OUT,...) 84 

ASSOCIATE SEGMENT WITH WORKSTATION 81, (21-44), (11-16), 
(GKSM-OUT,...) (61), 82 

COPY SEGMENT TO WORKSTATION (GKSM-OUT,...) (21-44), (11-16), (61) 
INSERT SEGMENT (21-44), (11-16), (61) 
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Segment Attributes 


SET SEGMENT TRANSFORMATION 91 
SET VISIBILITY 92 
SET HIGHLIGHTING 93 
SET SEGMENT PRIORITY 94 
SET DETECTABILITY 95 


Metafile Functions 


WRITE ITEM TO GKSM > 100 
E.4 Interpretation of Metafiles 

E.4.1 Introduction 
The interpretation of metafiles in GKS is described in 4.9 
[14]. The effects of INTERPRET ITEM for all types of metafile 
item are described in the following sections. Items are grouped 
by class of functionality. 

E.4.2 Control Items 
Interpretation of items in this class is described under the 
definitions of each item in E.5. ([14] reads "E.2.4" instead of 
"E.5" which we believe is an error). 

E.4.3 Output Primitives 
Interpretation of items in this class generates output 
corresponding to the primitive functions, except that 
coordinates of points are expressed in NDC. Primitive 
attributes bound to primitives are those which have originated 
from interpretation of primitive attribute items in this 
particular metafile (see E.4.4). 

E.4.4 Output Primative Attributes 


Aguilar 


Interpretation of items in this class sets values for use in 
the display of primitives subsequently originating from this 
particular metafile (see E.4.3). No changes are made to entries 
in the GKS state list. 
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E.4.5 Workstation Attributes 


Interpretation of items in this class has the same effect as 
invocation of the corresponding GKS functions shown in Table 
El. The GKS functions are performed on all active workstations. 


E.4.6 Transformations 


Interpretation of a clipping rectangle item sets values for use 
in clipping output primitives subsequently originating from 
this particular metafile. No changes are made to entries in the 
GKS state list. Interpretation of other items in this class 
(WORKSTATION WINDOW and WORKSTATION VIEWPORT) causes the 
invocation of the corresponding GKS functions on all active 
workstations. 


E.4.7 Segment Manipulation 
Interpretation of items in this class has the same effect as 


invocation of the corresponding GKS functions shown in Table 
El. (Item 84 causes an invocation of DELETE SEGMENT.) 


E.4.8 Segment Attributes 
Interpretation of items in this class has the same effect as 
invocation of the corresponding GKS functions shown in Table 
El. 
E.5 Control Items 
FILE HEADER 


| cksm | N | D|V|H]|T]|L[|I]|R][|F]R | ZERO | ONE 


All fields in the file header item have fixed length. Numbers are 
formated according to ISO 6093 - Format FI. 


General Information: 


GKSM 4 bytes containing string ' GKSM' 

N 40 bytes containing name of author/installation 

D 8 bytes date (year/month/day, e.g., 79/12/31) 

V 2 bytes version number: the metafile described here has 
version number 1 

H 2 bytes integer specifying how many bytes of the string ’GKSM’ 
are repeated at the beginning of each record. 
Possible values: 0, 1, 2, 3, 4 
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T 2 bytes length of item type indicator field 
L 2 bytes length of item data record length indicator field 
I 2 bytes length of field for each integer in the 


item data record (applied to all data marked (i) 
in the item description) 


R 2 bytes length of field for each real in the item data record 
(applies to all data marked (r) in the item 
description). 


Specification of Number Representation: 


F 2 bytes Possible values: 1, 2. This applies to all data 
in the items marked (i) or (r) and to item type 
and item data record length: 
1: all numbers are formatted according to ISO 6093 
2: all numbers (except in the file header) are 
stored in an internal binary format 

RI 2 bytes Possible values: 1, 2. This is the number 
representation for data marked (r): 
1 = real, 2 = integer 

ZERO 11 bytes integer equivalent to 0.0, if RI 

ONE 11 bytes integer equivalent to 1.0, if RI 


2 
2 


After the file header, which is in fixed format, all values in 
the following items are in the format defined by the file 
header. For the following description, the setting: 


H= 4; T= 3; F=1 


is assumed. In addition to formats (c), (i) and (r), which are 
already described, (p) denotes a point represented by a pair of 
real numbers (2r). The notation allows the single letter to be 
preceded by an expression, indicating the number of values of 
that type. 


{Explanatory comments have been added to some item 
specifications; these are not part of the GKS Appendix E and 
they are enclosed in braces {}. A complete definition of the 
generation and interpretation of the GKSM items is given by the 
definition of the corresponding GKS functions [14].} 
END ITEM 
"GKSM 0’ | L | 


Last item of every GKS Metafile. Sets condition for the error. 
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CLEAR WORKSTATION 


| “SEKSMOAS A] Beje 
Requests CLEAR WORKSTATION on all active workstations. 


C(i): clearing control flag 


(0 = CONDITIONAL, 1 = ALWAYS) 


REDRAW ALL SEGMENTS ON WORKSTATION 


| ‘GksM 3’ | L | R | 


Requests UPDATE WORKSTATION on all active workstations. 


R(i): regeneration flag 


(0 = PERFORM, 1 = SUSPEND) 


DEFERRAL STATE 


| ‘cksmM 4” |L]|D[R] 
Requests SET DEFERRAL STATE on all active workstations. 


D(i): deferral mode 
(0 = ASAP, 1 = BNIG, 2 = BNIL, 3 = ASTI) 


R(i): implicit regeneration mode 
(0 = ALLOWED, 1 = SUPPRESSED) 


{This item provides control over the occurrence of the visual 
effect of GKS functions in order to optimize the use of 
workstation capabilities according to application needs.) 


MESSAGE 
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| ’GksmM 5’ | L | N | T | 
Requests MESSAGE on all active workstations. 
N(i): number of characters in string 


T(Nc): string with N characters. 


(The message is not part of a metafile output primitives; the 
message is only for interpretation by workstation operators.) 
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| ‘GksmM 6 | L | FI |L]|M]|I]|R] 


Requests ESCAPE 


FI(i): function identifier 

L(i): length of integer data in data record 
M(i): length of real data in data record 
I(Li): integer data 

R(Mr): real data. 


(This item permits the invocation of a specific non-standard 
escape function FI. The execution of the function with the 
given parameters must not alter the GKS state list nor produce 
geometrical output.) 


E.G Items for Output Primitives 
POLYLINE 


| ’GKsM 11” | L | N | P | 


N(i): number of points of the polyline 
P(Np): list of points 
POLYMARKER 


| ’GKSM 12” | L | N | P | 


N(i): number of points 
P(Np): list of points. 
TEXT 


| ‘GKSM 13” | L | P| N|T | 


P(p): starting point of character string 

N(i): number of characters in string T 

T(Nc): string with N characters from the set of ISO 646 
FILL AREA 

| ’GksM 14! | L | N | P | 

N(i): number of points 

P(Np): list of points. 
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CELL ARRAY 
| GKM 15 | L| P | Q|R]|N]|M[| ec] 
P(p),Q(p),R(p): coordinates of corner points of pixel array 
(P and Q are the images of the points P and 


Q specified in the function CELL ARRAY and 
R is another corner) 


M(i): number of rows in array 
N(i): number of columns in array 
CT (MNi) : array of colour indices stored row by row 


(This item permits passing raster images to GKS. The raster 
image is defined by the colour index matrix CT, and its World 
Coordinate position given by points P and Q.) 


GENERALIZED DRAWING PRIMITIVE 
['6égsm 16: | L | cr |N|P[L]|M]|TI]|R] 


GDP identifier 

number of points 

list of points 

length of integer data in data record 
length of real data in data record 
integer data 

real data. 


Ne vay SE 
oe oe 


Roe Sto be 


ee EOB Joe Be yon 


DHE EFUWVAD 
pete ieee ae 


{This item provides a standard way for drawing additional 
non-standard output primitives. The generalized drawing 
primitive GI is drawn according to the point list P and the 
data record in I and R.} 
E.7 Items for Output Primitive Attributes 
POLYLINE INDEX 
| /GKSM 21” | L | LT | 


LT(i): linetype 
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LINEWIDTH SCALE FACTOR 
| ’GKSM 23” | L | LW | 
LW(r): linewidth scale factor 
{In GKS, the line width is not affected by GKS transformations. 
However, the effective line width is calculated as the product 
of the nominal line width times the line width scale factor in 
effect when a line is drawn. } 

POLYLINE COLOUR INDEX 
| *’Gxsm 24” | L | cr | 
CI(i): polyline colour index 

POLYMARKER INDEX 
| ’GKSM 25’ | L | I | 
I(i): polymarker index 

MARKER TYPE 
| ’GKsM 26’ | L | MT | 
MT(i): marker type 


MARKER SIZE SCALE FACTOR 


| “GRSM 27” | L | Ms | 

MS (r): marker size scale factor 

{In GKS, the marker size is not affected by GKS 
transformations. However, the effective marker size is 


calculated as the product of the nominal marker size times the 
marker size scale factor in effect when a marker is drawn. } 


POLYMARKER COLOUR INDEX 
| ’GksM 28’ | L | CI | 


CI(i): polymarker colour index 
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TEXT INDEX 
| ’GkKsM 29” | L | 1 | 
I(i): text index 
TEXT FONT AND PRECISION 
| ’GksM 30” | L | F | P | 
) text font 
): text precision 
= STRING, 1 = CHAR, 2 = STROKE) 
CHARACTER EXPANSION FACTOR 
| ’GKSM 31’ | L | CEF | 
CEF (r): character expansion factor 
{This item allows the manipulation of the width/height of the 
character body. The width of the character body is scaled by 
the CEF factor. } 
CHARACTER SPACING 
| ‘GksM 32” | L | cs | 
CS(r): character spacing 
TEXT COLOUR INDEX 
| /GKSM 33” | L | CI | 


CI (i): text colour index 
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CHARACTER VECTORS 


| ‘GKSM 34” | L | cH | cw | 


CH(2r): character height vector 
CW(2r): character width vector 
Note: These vectors are the height and width vectors described 


in 4.4.5 of [14]. 


{The character height vector is parallel to the character up 
vector and has a length equal to character height. The 
character height specifies the height of a capital letter. The 
character width vector is perpendicular to the height vector, 
in the direction of the character baseline, and has the same 
length. } 


TEXT PATH 
| ’GKSM 35’ | L | P | 


P(i): text path 
(0 = LEFT, 1 = RIGHT, 2 = UP, 3 = DOWN) 


TEXT ALIGNMENT 


| ’GksM 36’ | L | H | Vv | 


H(i): horizontal character alignment 
(0 = NORMAL, 1 = LEFT, 2 = CENTRE, 3 = RIGHT) 
V(i): vertical character alignment 
(0 = NORMAL, 1 = TOP, 2 = CAP, 3 = HALF, 4 = BASE, 
5 = BOTTOM) 


FILL AREA INDEX 
| ’GKsM 37” | L | TI | 
I(i): fill area index 
FILL AREA INTERIOR STYLE 
| ‘GKsM 38’ | L | s | 


S(i): fill area interior style 
(0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH) 
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FILL AREA STYLE INDEX 
| ‘GKSM 39” | L | SI | 
SI(i): fill area style index 
FILL AREA COLOUR INDEX 
| *’Gxsm 40” | L | cr | 
CI(i): fill area colour index 
PATTERN SIZE 
| ’GKSM 41’ | L | Pw | PH | 


PW(2r): pattern width vector 
PH(2r): pattern height vector 


December 1985 


{One style for filling areas is with a pattern of color cells. 
Such a pattern is defined by an array of color indices which is 
mapped into a pattern rectangle with dimensions given by PW and 


PH. } 


PATTERN REFERENCE POINT 


| ’GKSM 42” | L | P | 


P(p): reference point 


{One style for filling areas is with a pattern of color cells. 
Such a pattern is defined by an array of color indices which is 
mapped into a pattern rectangle whose lower left corner is 


given by P.} 
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ASPECT SOURCE FLAGS 
| ’GKSM 43” | L | F | 


F(I3i): aspect source flags 
(0 = BUNDLED, 1 = INDIVIDUAL) 


{An application can set an output primitive attribute to either 
bundled or individual. Bundled attributes are 
workstation-dependent, their binding is delayed, and their 
values can change dynamically. Individual attributes are global 
attributes, they are bound immediately, and their value is 
static and cannot be manipulated. } 


PICK IDENTIFIER 
| ’GksM 44” | L | P | 
P(i): pick identifier 
E.8 Items for Workstation Attributes 
POLYLINE REPRESENTATION 


| /GKSM 51” | L [a FET] awe) cers) | 


I(i): polyline index 

LT(i): linetype number 

LW(r): linewidth scale factor 
CI(i): polyline colour index 


POLYMARKER REPRESENTATION 
| ’GKSM 52” | L | IT | MT | Ms | cr | 


Mes polymarker index 

i): marker type 

r): marker size scale factor 
i): polymarker colour index 
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TEXT REPRESENTATION 
| ‘GkKsM 53? | L | 1 | F | P | CEF | cs | cr | 


text index 

text font 

text precision 
STRING, 1 = CHAR, 2 = STROKE) 
r): character expansion factor 
CS(r)*: character spacing 
CI (i): text colour index 
FILL AREA REPRESENTATION 

| 'GKsM 54” | ETE e sr. ser | 

I(i): fill area index 
S(i): fill area interior style 
(0 = HOLLOW, 1 = SOLID, 2 = PATTERN, 3 = HATCH) SI(i): fill 
area style index 
CI(i): fill area colour index 


PATTERN REPRESENTATION 


| “ERS 55” [ate [<r | at) | | er | 


I(i): pattern index 

N(i): number of columns in array* 

M(i): number of rows in array 

CT(MNi): table of colour indices stores row by row 


{* The ANSI document reads "area" instead of "array". } 


{One style for filling areas is with a pattern of color cells. 
Such a pattern is defined by a pattern representation. } 


COLOUR REPRESENTATION 
| ’GKSM 56’ | L | CI | RGB | 


ETI). colour index 
RGB(3r): red, green, blue intensities 
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E.9 Items for Transformations 
CLIPPING RECTANGLE 
| ’GKSM 61” | L | c | 


C(4r): limits of clipping rectangle (XMIN, XMAX, YMIN, YMAX) 


WORKSTATION WINDOW 

| ’GKSM 71” | L | w | 

W(4r): limits of workstation window (XMIN, XMAX, YMIN, YMAX) 
{GKS includes a workstation transformation that maps a 


rectangle of the NDC space (a workstation window) into a 
rectangle of the device coordinate space (a workstation 


viewport) .} 
WORKSTATION VIEWPORT 

| ’GksM 72” | L | v | 

V(4r): limits of workstation viewport (XMIN, XMAX, YMIN, YMAX) 


E.10 Items for Segment Manipulation 


CREATE SEGMENT 

| ’GKSM 81’ | L |s] 

S(i): segment name 
CLOSE SEGMENT 

| ’GKSM 82” | L | 

indicates end of segment 
RENAME SEGMENT 

| ‘GKSM 83’ | L | so | SN | 


SO(i): old segment name 
SN(i): new segment name 
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DELETE SEGMENT 
| ’GksM 84” | L |s] 
S(i): segment name 
E.11 Items for Segment Attributes 
SET SEGMENT TRANSFORMATION 
| ‘GKSM 91” | L | s | M | 
S(i): segment name 
M(6r): transformation matrix 
upper and center rows of a 3x3 matrix representing 
a 2D homogeneous transformation [9] 
M 11 M 12 M13 M21 M22 M 23 
{This differs from the ANSI X3.124 Jan. 5 1984 document, in the 
matrix elements indicated. We believe there is an error in such 
document. } 
SET VISIBILITY 
| ‘GksmM 92” | L] S | v| 
S(i): segment name 
V(i): visibility 
(0 = VISIBLE, 1 = INVISIBLE) 
SET HIGHLIGHTING 
| ’GksM 93’ | L | s | 8H | 
S(i): segment name 
H(i): highlighting 
(0 = NORMAL, 1 = HIGHLIGHTED) 
SET SEGMENT PRIORITY 
| eks 94" | L | S | P | 


S(i): segment name 
P(r): segment priority 
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SET DETECTABILITY 
| ’GksM 95’ | L | s | D | 
S(i): segment name 


D(i): detectability 
(0 = UNDETECTABLE, 1 = DETECTABLE) 


E.12 User Items 
USER ITEM 
"GKSMXxx’ | L | D | 


XXX > 100 
Dé user data (L bytes) 


(The PIGCF level U items are encoded as GKSM USER ITEM elements 
so that a PIGCF file will conform to the GKSM metafile 


specification.) 
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APPENDIX B 
Example of PIGCF Use in Conferencing 


This section presents an example illustrating the proposed PIGCF 
graphical component in an audio-graphics conference exchange. We 
present only the graphical part of the conference exchange, which 
actually would be complemented with speech. For the sake of briefness 
the example does not contain all the parameter negotiation that a 
conference set-up would require. 


The example is about an on-line audio-graphics conference between a 
Navy command and control center and a Navy task force. The PIGCF 
items shown do not belong to a single transmission stream. The stream 
they belong to is determined by the station that transmits them, and 
the identification of the transmitter belongs to lower level 
communication protocols. We use the character encoding, rather than 
the binary one, for this PIGCF example. We illustrate just a few of 
the possible groups of items that could be batched in this example. 
The plot of the example is as follows. 


The command center (center) establishes a conference with some ships 
in a task force (platforms) to coordinate the interception of an 
unidentified ship that has been sighted in a conflict area. After 
recalling graphical libraries, all conference sites can see in their 
screens a map of the sighting area as well as iconic representations 
of the task force ships. Then the center interactively draws an 
iconic representation of the unidentified vessel, scales it, and 
places it in the sighting location. 


The platforms explain possible courses of action using graphical 
pointers. The center draws the expected trajectory of the 
unidentified ship and the platforms situate the task force icons at 
the expected points of interception. Then the center zooms into the 
interception area and the platforms use rubber bands to discuss 
interception maneuvers. 


Now we proceed to list the PIGCF items exchanged. The center 
initiates the conference graphical set-up with the FILE HEADER item 
to set basic representation parameters for the graphical 
information to be exchanged. This item can be interpreted 
according to its definition in E.5 [14]. The most important 
parameter selections for this example are: 


i) The items contain 0 characters of the "GKSM" string in the 


identification field of the item header. 
ii) The item type indicator field containing the PIGCF 


Aguilar [Page 45] 


RFC 965 December 1985 
A Format for a Graphical Communication Protocol 


item number is three bytes long in each item. 
iii) The integers are 4 bytes long, and the reals 6 bytes long. 
iv) The item data record length indicator is 2 bytes long. 


We will obey the PIGCF specification field lengths and the aforesaid 
field length settings. However, we will add one space before and 
after the a fa separator to improve legibility. Also, every item will 
be preceded with its name to help identification. 


FILE HEADER: 


| GKSM | center | 84/11/10 | 1 |0o|3]|2]|a4a]|6]|1i]|i1 


The center states the boundaries of the work station window for the 
conference. 


WORKSTATION WINDOW: | 71 | 24 | 0.0 0.5 0.0 0.375 | 


In this example, we assume that the conferencing work stations use 
world coordinates for the internal representation of positional 
information. Accordingly, the center states the boundaries of the 
world window for the normalization transformation used in the 
conference. 


SET WINDOW: | 134 | 28 | 0.0 320.0 0.0 240.0 | 


The center informs the location of its local NDC viewport, however, 
other conferees can choose different NDC viewports for the same 
transformation, but their work station window should include the 
conference’s. All systems record the conference: world window, NDC 
viewport, and work station widow. 


SET VIEWPORT: | 135 | 28 | 0.0 0.5 0.0 0.375 | 
The center recalls graphical libraries containing geographical maps 


of the crisis area and icons of the task forces in the area. It 
also displays a graphical object that provides a background picture. 


RECALL LIBRARY: | 139 | 9 | caribbean | 
DISPLAY OBJECT: | 128 | 11 | coast_lines | 
RECALL LIBRARY: | 139 | 10 | task_units | 


The center proceeds to instantiate one of the task forces in the 
task_units library. This is done by recalling some of the library 
objects and applying transformations to the objects, later. Since set 
window, set viewport, and recall library belong to the update 
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Group-2, they can be batched until display object, from update 
Group-l, is entered. The second recall library can be batched 
together with the following begin instantiation until display object 
is produced. The rest of the example contains more cases of item 
sequences which can be batched; however, for briefness we do not 
indicate any more of them. 


BEGIN INSTANTIATION: | 124 | 15 | US_CONSTITUTION | 
DISPLAY OBJECT: | 128 | 15 | US_CONSTITUTION | 
TRANSFORM OBJECT: | “126. | “550 | 15 | US_CONSTITUTION | 
0 O00) “Os n POLO" OUI - 0.07 | 
TRANSFORM OBJECT: | a26> |) 55. \| 15 | US_CONSTITUTION | 
0.1 0.0 0.312 0.0 0.1 0.078 | 
END INSTANTIATION: | 125 | o | 
BEGIN INSTANTIATION: | 124 | 13 | US_NEW_JERSEY | 
DISPLAY OBJECT: | 128 | 13 | US_NEW_JERSEY | 
TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY | 
Col ANWO OO OO. O 0] 
TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY | 
0.1 0.0 0.312 0.0 0.1 0.093 | 
END INSTANTIATION: laž YO 


Next the center sets values for two output primitive attributes in 
preparation for drawing a new icon on the screens. We assume that all 
the other attributes have been assigned default values as a result of 
the conference set-up. 


POLYLINE INDEX: | 21| ae | 20 | 
POLYLINE COLOUR INDEX: | 24 | 4 


The following items correspond to the interactive definition of the 
unidentified vessel. Since the definition is done interactively, the 
vessel image remains visible on the screens after definition. 


BEGIN DEFINITION: | 120 | 0 | 
POLYLINE: | 11 | 64 | Say 
0.047 0.063 0.063 0.047 0.125 0.047 0.14 0.063 0.047 0.047 | 
POLYLINE: (a e tie 3 | 

0.078 0.063 0.078 0.078 0.109 0.078 0.109 0.063 | 
END DEFINITION: | 121 | 8 | sighting | 


Then the unidentified vessel "sighting" is scaled and placed at the 
sighting site. 
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BEGIN INSTANTIATION: | 124 | 8 | sighting | 
TRANSFORM OBJECT: | 126 | 48 | 8 | sighting | 
OZ- sO O0 
OSO a02 = O0] 
TRANSFORM OBJECT: | 126 | 48 | 8 | sighting | 
0.1 0.0 0.156 
0.0 0.1 0.016 | 
END INSTANTIATION: i25 O] 


The center and the platforms use graphical pointer movements to 
discuss possible routes the unidentified vessel might follow. We only 
show a few pointer updates. In practice, there would typically be a 
large number of points transmitted to convey the movement of the 
pointers over the screens. 


from the center: 


POINTER TRACKING: | 137 | 16 | o | 0.39 0.032 | 
POINTER TRACKING: 137 | 16 0 0.388 0.035 
POINTER TRACKING: 137 | 16 0 0.388 0.039 
POINTER TRACKING: | 137 | 16 | o | 0.386 0.04 | 
from one of the platforms: 

POINTER TRACKING: 137 | 16 0 0.22 0.016 
POINTER TRACKING: 137 | 16 0 0.222 0.159 
POINTER TRACKING: | 137 | 16 | W || OS 
POINTER TRACKING: | 137 | 16 | o | 0.24 0.155 | 


The center now draws the expected route to be followed by the 
unidentified ship. This time the pointer trace is recorded on the 
screen by drawing a line. 


POINTER TRACKING: | 137 | 16 | 1 | 0.388 0.038 | 
POINTER TRACKING: | 137 | 16 | 1 | 0.386 0.038 | 
POINTER TRACKING: | 137 | 16 | 1 | 0.386 0.052 | 
POINTER TRACKING: 137 | 16 | 1 0.375 0.078 

POINTER TRACKING: | 137 | 16 1 0.369 0.105 

POINTER TRACKING: | 137 | 16 | 1 | 0.361 0.125 | 
POINTER TRACKING: | 137 | 16 | 1 | 0.352 0.144 | 
POINTER TRACKING: | 137 | 16 | 1 | 0.351 0.156 | 
POINTER TRACKING: | 137 | 16 | 1 | 0.35 0.16 | 


A platform moves the two US ship icons to interception positions. 
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TRANSFORM OBJECT: | 126 | 55 | 15 | US_CONSTITUTION | 
1.0 0.0 0.16 
0.0 1.0 -0.046 | 

TRANSFORM OBJECT: | 126 | 53 | 13 | US_NEW_JERSEY | 
150” “OO OANI 
0.0 1.0 -0.034 | 


The center zooms into the interception area in order to obtain a 
larger view for further discussion. 


WORKSTATION WINDOW: | 71 | 24 | 0.286 0.403 0.077 0.177 | 


The two platforms indicate their striking ranges using circular 
rubber bands centered at each ship. For each platform, we show first 
the echo reference point and then two echo feedback points. Typically 
there will be a large number of feedback points. 


RUBBER BAND: | 138 | 10 | 0 | 0.335 0.125 | 
RUBBER BAND: 138 | 10 3 | 0.35 0.128 
RUBBER BAND: | 138 | 10 | 3 | 0.37 0.128 
RUBBER BAND: | 138 | 10 | o | 0.384 0.13 | 
RUBBER BAND: | 138 | 10 | 3 | 0.367 0.128 | 
RUBBER BAND: | 138 | 10 | 3 | 0.346 0.129 | 


Once the interception strategy has been agreed upon, the center zooms 
out to the original, larger picture. 


WORKSTATION WINDOW: | 71 | 24 | 0.0 0.5 0.0 0.375 | 

The center terminates the conference 

END ITEM: | 0 | o] 

At the end of a conference, the final pictures remain visible on the 
screens. In addition, the PIGCF items will be recorded in its 
entirety in order to play back the conference session if necessary. 


The conference record could also be sent to other locations as part 
of a multi-media message. 
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